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REMARKS 

Reconsideration and further examination of the application in light of these remarks 
are respectfully requested. 

Claims 1-37 stand finally rejected under 35 U.S.C. §103 as being obvious over U.S. 
Patent No. 5,742,812 issued to Baylor et al. (hereafter "Baylor") in view of U.S. Patent No. 
5,634,122 issued to Loucks et al. (hereafter "Loucks"). Applicant respectfully traverses the 
rejection. 

Claim 1 recites in relevant part: 

"A computerized data file system, comprising:" 
"a first process . . ." 

"a second process that generates a first message requesting that said second 
process be granted by said first process a plurality of tokens required for said second 
process to modify at least one characteristic of said file". 

In other words, with applicant's invention, a single message conveys a request, not for one, 

but for a plurality of tokens. 

The final Office action, at ^[4, relies on the Loucks reference as purportedly teaching a 
single message requesting a plurality of tokens that are required to modify a desired file. 
Applicant submits that, with all due respect, a fair and proper reading of Loucks does not 
support such a conclusion. Instead, Loucks, like the art described in the Background section 
of this application, can only request one token per message. 

The final Office action cites to the Abstract and to Col. 3, lines 45-52 of Loucks as 
purportedly teaching a single message that requests a plurality of tokens. In the Abstract, 
Loucks explicitly states that tokens are only requested one at a time. Abstract, lines 5-7 
("Each requested operation checks for the proper token . If the token is not held by the proc- 
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ess, it is requested.") The Abstract also notes that Loucks token manager can request 
authorization tokens from a local token manager, but Loucks provides absolutely no teaching 
or suggestion that multiple tokens can be requested by the token manager in a single mes- 
sage. Instead, given the explicit language in the Abstract at lines 5-7 quoted above, the only 
proper teaching of Loucks is that tokens must be requested one at a time. 

The other section of Loucks that was cited in the final Office Action, Col. 3, lines 45- 
52, states as follows: 

means for requesting authorization for a computer implemented process to perform an 
operation on shared data; means for managing requests generated by the means for 
requesting; and means for granting authorization tokens allowing an operation to be 
performed on the shared data, the means for granting being responsive to the means 
for managing. 

Applicant agrees that this excerpt states that Loucks' token manager grants multiple tokens. 
However, this excerpt is completely silent as to how the computer implemented process 
looking for authorization requests one or more tokens, and thus provides no teaching or sug- 
gestion for a process that generates a single message requesting a plurality of tokens in order 
to modify a file. It is improper for the final Office action to read into this excerpt from 
Loucks particular teachings that are wholly absent. Again, this excerpt provides no teaching 
or suggestion for the generation of single message that requests a plurality of tokens, as re- 
cited in claim 1. 

Consideration of Loucks in its entirety, moreover, clearly demonstrates that tokens 
are requested one at a time. In particular, the following excerpts from Loucks all show that 
tokens are requested one at a time: 
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(1) Col. 6, lines 28-29 ("When the token requester, mtkr 418, of an MDFS cli- 
ent requests a token from the token manager . . ."); 

(2) Col. 6, lines 3 1-32 ("it may request a new token from the local token man- 
ager..."); 

(3) Col. 7, lines 4-5 ("If the requested token does not conflict . . ."); 

(4) Col. 9, lines 36-37 ("if the Stash token is requested . . ."); 

(5) Fig. 8A, block 804 ("Request token from ltkm"); 

(6) Fig. 8B, block 816 ("Wait for token request"); 

(7) Fig. 9A, block 903 ("Get Open_Write token for fileset y"); 

(8) Fig. 9B, block 938 ("Identify Requester and requested token ") 

All of the above excerpts clearly demonstrate that a request issued by one of Loucks' 
processes is only for a single token. There is no teach or suggestion by Loucks for a single 
message that can somehow request a plurality of tokens. Loucks does state that, over time, 
multiple tokens can be requested (Col. 7, lines 55-57), but the only teaching provided by 
Loucks is that multiple messages or requests must be issued in order to obtain those multiple 
tokens. Because Loucks fails to teach or suggest a single message for requesting a plurality 
of tokens, the rejection of claim 1 should be withdrawn. The rejection of claims 2-5, which 
depend from claim 1, should also be withdrawn. Furthermore, claims 11-18, 20-31 and 35- 
36 all recite a single message or request for a grant of a plurality of tokens. Accordingly, 
these claims are also allowable over the art of record for the same reasons set forth above. 

Claims 6-10, 19 and 32-34 all recite the issuance of a single message that grants a 
plurality of tokens. Loucks also fails to provide any teaching or suggestion for the issuance 
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of a single message granting a plurality of tokens. Instead, Loucks repeatedly states that only 
a single token is ever issued at any one time. For example, block 826 of Fig. 8B recites the 
step "Grant token", i.e., one token. Block 916 of Fig. 9A and block 956 of Fig. 9B both re- 
cite the step "Grant token" , i.e., one token. Thus, the only teaching provided by Loucks is to 
grant a single token at any one time. There is no teaching or suggestion by Loucks for some- 
how granting multiple tokens in a single message. 

Applicant submits that the application is in condition for allowance and early favor- 
able action is requested. 

Please charge any additional fee occasioned by this paper to our Deposit Account 
No. 03-1237. 



Respectfully submitted, 




Michael R. Reinemann 
Reg. No. 38,280 
Tel. (617) 951-2500 



Please direct all correspondence to: 

IP Administration Legal Department, 
M/S35 

Hewlett-Packard Co. 

P.O. Box 272400 

Fort Collins, CO 80527-2400 
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